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Abstract 


This  study  presents  findings  from  an  empirical  study  directed  at 
understanding  the  roles,  forms,  and  consequences  arising  in  requirements  for  open 
source  software  (OSS)  development  efforts.  Five  open  source  software  development 
communities  are  described,  examined,  and  compared  to  help  discover  what 
differences  may  be  observed.  At  least  two  dozen  kinds  of  software  informalisms  are 
found  to  play  a  critical  role  in  the  elicitation,  analysis,  specification,  validation,  and 
management  of  requirements  for  developing  OSS  systems.  Subsequently, 
understanding  the  roles  these  software  informalisms  take  in  a  new  formulation  of  the 
requirements  development  process  for  OSS  is  the  focus  of  this  study.  This  focus 
enables  considering  a  reformulation  of  the  requirements  engineering  process  and  its 
associated  artifacts  or  (in)formalisms  to  better  account  for  the  requirements  when 
developing  OSS  systems.  Other  findings  identify  how  OSS  requirements  are 
decentralized  across  multiple  informalisms,  and  to  the  need  for  advances  in  how  to 
specify  the  capabilities  of  existing  OSS  systems. 
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1 


Introduction 


The  focus  in  this  paper  is  directed  at  understanding  the  requirements 
processes  for  open  source  software  (OSS)  development  efforts,  and  how  the 
development  of  these  requirements  differs  from  those  traditional  to  software 
engineering  and  requirements  engineering  [5,  9,  23,  40].  This  study  is  about  ongoing 
discovery,  description,  and  abstraction  of  OSS  development  (OSSD)  practices  and 
artifacts  in  different  settings  across  different  communities.  It  is  about  expanding  our 
notions  of  what  requirements  need  to  address  to  account  for  OSSD.  Subsequently, 
these  are  used  to  understand  what  OSS  communities  are  being  examined,  and  what 
characteristics  distinguish  one  community  from  another.  This  chapter  also  builds  on, 
refines,  and  extends  earlier  study  on  this  topic  [12,  14,  24,  49,  53],  as  well  as 
identifying  implications  for  what  requirements  arise  when  developing  different  kinds 
of  OSS  systems. 

This  study  reports  on  findings  and  results  from  an  ongoing  investigation  of  the 
socio-technical  processes,  work  practices,  and  community  forms  found  in  OSSD  [51, 
53,  56],  The  purpose  of  this  multi-year  investigation  is  to  develop  narrative,  semi- 
structured  (i.e.,  hypertextual),  and  formal  computational  models  of  these  processes, 
practices,  and  community  forms  [24,  57],  This  chapter  presents  a  systematic 
narrative  model  that  characterizes  the  processes  through  which  the  requirements  for 
OSS  systems  are  developed.  The  model  compares  in  form,  and  presents  an  account 
of,  how  software  requirements  differ  across  traditional  software  engineering  and 
OSS  approaches.  This  model  is  descriptive  and  empirically  grounded.  The  model  is 
also  comparative  in  that  it  attempts  to  characterize  an  open  source  requirements 
engineering  process  that  transcends  the  practice  in  a  particular  project,  or  within  a 
particular  community.  This  comparative  dimension  is  necessary  to  avoid  premature 
generalizations  about  processes  or  practices  associated  with  a  particular  OSS 
system  or  those  that  receive  substantial  attention  in  the  news  media  (e.g.,  the 
GNU/Linux  operating  system).  Such  comparison  also  allows  for  system  projects  that 
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may  follow  a  different  form  or  version  of  OSSD  (e.g.,  those  in  the  higher  education 
computing  community  or  networked  computer  game  arena).  Subsequently,  the 
model  is  neither  prescriptive  nor  proscriptive  in  that  it  does  not  characterize  what 
should  be  or  what  might  be  done  in  order  to  develop  OSS  requirements,  except  in 
the  concluding  discussion,  where  such  remarks  are  bracketed  and  qualified. 

Comparative  case  studies  of  requirements  or  other  software  development 
processes  are  also  important  in  that  they  can  serve  as  foundation  for  the 
formalization  of  our  findings  and  process  models  as  a  process  meta-model  [37], 

Such  a  meta-model  can  be  used  to  construct  a  predictive,  testable,  and 
incrementally  refined  theory  of  OSSD  processes  within  or  across  communities  or 
projects.  A  process  meta-model  is  also  used  to  configure,  generate,  or  instantiate 
Web-based  process  modeling,  prototyping,  and  enactment  environments  that  enable 
modeled  processes  to  be  globally  deployed  and  computationally  supported  [e.g.,  24, 
38,  39,  57],  This  may  be  of  most  value  to  other  academic  research  or  commercial 
development  organizations  that  seek  to  adopt  "best  practices"  for  OSSD  processes 
that  are  well  suited  to  their  needs  and  situation.  Therefore,  the  study  and  results 
presented  in  this  report  denote  a  new  foundation  on  which  computational  models  of 
OSS  requirements  processes  may  be  developed,  as  well  as  their  subsequent 
analysis  and  simulation  (cf.  [48,  57]). 

The  study  reported  here  entails  the  use  of  empirical  field  study  methods  [67] 
that  follow  conform  to  the  principles  for  conducting  and  evaluating  interpretive 
research  design  [28]  as  identified  earlier  [49], 
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2.  Understanding  OSS  Development  across 
Different  Communities 


We  assume  there  is  no  general  model  or  globally  accepted  framework  that 
defines  how  OSS  is  or  should  be  developed.  Subsequently,  our  starting  point  is  to 
investigate  OSS  practices  in  different  communities  from  an  ethnographically 
informed  perspective  [20,  28,  62],  We  have  chosen  five  different  communities  to 
study.  These  are  centered  about  the  development  of  software  for  networked 
computer  games,  Internet/Web  infrastructure,  bioinformatics,  higher  education 
computing,  and  military  computing.  The  following  sections  briefly  introduce  and 
characterize  these  OSS  sub-domains.  Along  the  way,  example  software  systems  or 
projects  are  highlighted  or  identified  via  external  reference/citation,  which  can  be 
consulted  for  further  information  or  review. 

2.1.  Networked  Computer  Game  Worlds 

Participants  in  this  community  focus  on  the  development  and  evolution  of  first 
person  shooters  (FPS)  games  (e.g.,  Quake  Arena,  Unreal  Tournament),  massive 
multiplayer  online  role-playing  games  (e.g.,  World  of  Warcraft,  Lineage,  EveOnline, 
City  of  Heroes),  and  others  (e.g.,  The  Sims  (Electronic  Arts),  Grand  Theft  Auto 
(Rockstar  Games)).  Interest  in  how  to  develop  or  modify  networked  computer  games 
and  gaming  environments,  as  well  as  their  single-user  counterparts,  have  exploded 
in  recent  years  as  a  major  (now  global)  mode  of  entertainment,  playful  fun,  and 
global  computerization  movement  [50],  The  release  of  DOOM  [31],  an  early  first- 
person  action  game,  onto  the  Web  in  open  source  form1  in  the  mid  1990’s,  began 


i  The  end-user  license  agreement  for  games  that  allow  for  end-user  created  game  mods  often 
stipulate  that  the  core  game  engine  (or  retail  game  software  product)  is  protected  as  closed  source, 
proprietary  software  that  cannot  be  examined  or  redistributed,  while  any  user  created  mod  can  only 
be  redistributed  as  open  source  software  that  cannot  be  declared  proprietary  or  sold  outright,  and 
must  only  be  distributed  in  a  manner  where  the  retail  game  product  must  be  owned  by  any  end-user 
of  a  game  mod.  This  has  the  effect  of  enabling  a  secondary  market  for  retail  game  purchases  by  end- 
users  or  other  game  modders  who  are  primarily  interested  in  accessing,  studying,  playing,  further 
modifying,  and  redistributing  a  game  mod. 
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what  is  widely  recognized  the  landmark  event  that  launched  the  development  and 
redistribution  of  computer  game  mods  [6,  49,  50], 

Mods2  are  variants  of  proprietary  (closed  source)  computer  game  engines  that 
provide  extension  mechanisms  like  game  scripting  languages  (e.g.,  UnrealScript  for 
mod  development  with  Unreal  game  engines)  that  can  be  used  to  modify  and  extend 
a  game,  and  these  extensions  are  licensed  for  distribution  in  an  open  source 
manner.  Mods  are  created  by  small  numbers  of  users  who  want  and  are  able  to 
modify  games,  compared  to  the  huge  numbers  of  players  that  enthusiastically  use 
the  games  as  provided.  The  scope  of  mods  has  expanded  to  now  include  new  game 
types,  game  character  models  and  skins  (surface  textures),  levels  (game  play 
arenas  or  virtual  worlds),  and  artificially  intelligent  game  bots  (in-game  opponents). 

Perhaps  the  most  widely  known  and  successful  game  mod  is  Counter-Strike, 
which  is  a  total  conversion  of  Valve  Software's  Half-Life  computer  game  developed  by 
two  game  programmers  (Valve  Software  has  since  commercialized  cs  and  many 
follow-on  versions).  Millions  of  copies  of  cs  have  been  distributed,  and  millions  of 
people  have  player  cs  over  the  Internet,  according  to  http://counterstrikesource.net/. 
Other  popular  computer  games  that  are  frequent  targets  for  modding  include  the 
Quake,  Unreal,  Half-Life,  and  Crysis  game  engines,  NeverWinter  Nights  for  role-playing 
games,  motor  racing  simulation  games  (e.g.,  GTR  series),  and  even  the  massively 
popular  World  of  Warcraft  (which  only  allows  for  modification  of  end-user  interfaces). 
Thousands  of  game  mods  are  distributed  through  game  mod  portals  like 
MODDB.com.  However,  many  successful  game  companies  including  Electronic  Arts 
and  Microsoft  do  not  embrace  nor  encourage  game  modding,  and  do  not  provide 
end-user  license  agreements  that  allow  game  modding  and  redistribution. 


2  For  introductory  background  on  computer  game  mods,  see 
http://en.wikipedia.org/wiki/Mod  (computer  gaming). 
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2.2.  Internet/Web  Infrastructure 

Participants  in  this  community3  focus  on  the  development  and  evolution  of 
systems  like  the  Apache  web  server,  Mozilla/Firefox  Web  browser4,  GNOME  and  K 
Development  Environment  (KDE)  for  end-user  interfaces,  the  Eclipse  and  NetBeans 
interactive  development  environments  for  Java-based  Web  applications,  and 
thousands  of  others.  This  community  can  be  viewed  as  the  one  most  typically 
considered  in  popular  accounts  of  OSS  projects.  The  GNU/Linux  operating  system 
environment  is  of  course  the  largest,  most  complex,  and  most  diverse  sub¬ 
community  within  this  arena,  so  much  so  that  it  merits  separate  treatment  and 
examination.  Many  other  Internet  or  Web  infrastructure  projects  constitute 
recognizable  communities  or  sub-communities  of  practice.  The  software  systems 
that  are  the  focus  generally  are  not  standalone  end-user  applications,  but  are  often 
targeted  at  system  administrators  or  software  developers  as  the  targeted  user  base, 
rather  than  the  eventual  end-users  of  the  resulting  systems.  However,  notable 
exceptions  like  Web  browsers,  news  readers,  instant  messaging,  and  graphic  image 
manipulation  programs  are  growing  in  number  within  the  end-user  community 

2.3.  Bioinformatics 

Participants  in  this  community5  focus  on  the  development  and  evolution  of 
software  systems  supporting  research  into  bioinformatics  and  related  computing- 


3  The  SourceForge  web  portal  (http://www.sourceforge.net),  the  largest  associated  with  the 
OSS  community,  currently  stores  information  on  more  than  1,750K  registered  users  and  developers, 
along  with  nearly  200K  OSSD  projects  (as  of  July  2008),  with  more  than  10%  of  those  projects 
indicating  the  availability  of  a  mature,  released,  and  actively  supported  software  system.  However, 
some  of  the  most  popular  OSS  projects  have  their  own  family  of  related  projects,  grouped  within  their 
own  portals,  such  as  for  the  Apache  Foundation  and  Mozilla  Foundation. 

4  It  is  reasonable  to  note  that  the  two  main  software  systems  that  enabled  the  World  Wide 
Web,  the  NCSA  Mosaic  Web  browser  (and  its  descendants,  like  Netscape  Navigator,  Mozilla,  Firefox, 
and  variants  like  K-Meleon,  Konqueror,  SeaMonkey,  and  others),  and  the  Apache  Web  server 
(originally  know  as  httpd)  were  originally  and  still  remain  active  OSSD  projects. 

5  For  information  about  OSS  projects,  activities,  and  events  in  this  community,  see 
http://www.bioinformatics.org,  http://www.open-bio.org,  and  http://www.open- 
bio.org/wiki/Upcoming  BOSC  conference. 
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intensive  biological  research  efforts.  In  contrast  to  the  preceding  two  development 
oriented  communities,  OSS  plays  a  significant  role  in  scientific  research 
communities.  For  example,  when  scientific  findings  or  discoveries  resulting  from  in 
silico  experimentation  or  observations  are  reported6,  then  members  of  the  relevant 
scientific  community  want  to  be  assured  that  the  results  are  not  the  byproduct  of 
some  questionable  software  calculation  or  opaque  processing  trick.  In  scientific 
fields  like  astrophysics  that  critically  depend  on  software,  open  source  is  considered 
an  essential  precondition  for  research  to  proceed,  and  for  scientific  findings  to  be 
trusted  and  open  to  independent  review  and  validation.  Furthermore,  as  discoveries 
in  bioinformatics  are  made,  this  in  turn  often  leads  to  modification  or  extension  of  the 
astronomical  software  in  use  in  order  to  further  explore  and  analyze  newly  observed 
phenomena,  or  to  modify/add  capabilities  to  how  in  silico  mechanisms  operate. 

2.4.  Higher  Education  Computing 

Participants  in  this  community  focus  on  the  development  and  evolution  of 
software  supporting  educational  and  administrative  operations  found  in  large 
universities  or  similar  institutions.  This  community  should  not  in  general  be 
associated  with  the  activities  of  academic  computer  scientists  nor  of  computer 
science  departments,  unless  they  specifically  focus  on  higher  education  computing 
applications  (which  is  uncommon).  People  who  participate  in  this  community 
generally  develop  software  for  academic  teaching  or  administrative  purposes  in 
order  to  explore  topics  like  course  management  (Sakai,  Moodle ),  campuswide 
information  systems/portals  ( uPortal ),  Web-based  academic  applications  (Fluid),  and 
university  e-business  systems  [54]  (for  collecting  student  tuition,  research  grants 


e  For  example,  see  [4].  The  OSS  processing  pipelines  for  each  sensor  or  mass  spectrometer 

are  mostly  distinct  and  are  maintained  by  different  organizations.  However,  their  outputs  must  be 
integrated,  and  the  data  source  must  be  registered  and  oriented  for  synchronized  alignment  or 
overlay,  then  composed  into  a  final  representation  (e.g.,  see  [4]).  Subsequently,  many  OSS  programs 
may  need  to  be  brought  into  alignment  for  such  a  research  method  and  observation, for  a  scientific 
discovery  to  be  claimed  and  substantiated  [41]. 
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administration,  payroll,  etc.  ~  Kuali).  Projects  in  this  community7  are  primarily 
organized  and  governed  through  multi-institution  contracts,  annual  subscriptions, 
and  dedicated  staff  assignments  [64],  Furthermore,  it  appears  that  software 
developers  in  this  community  are  often  not  the  end-users  of  the  software  the 
develop,  in  contrast  to  most  OSS  projects.  Accordingly,  it  may  not  be  unreasonable 
to  expect  that  OSS  developed  in  this  community  should  embody  or  demonstrate 
principles  or  best  practices  in  administrative  computing  found  in  large  public  or  non¬ 
profit  enterprises,  rather  than  OSSD  projects  focused  on  Internet/Web  infrastructure. 
This  includes  the  practice  of  developing  explicit  software  requirements  specification 
documents  prior  to  undertaking  system  development.  Furthermore,  much  like  the 
bioinformatics  community,  members  of  this  community  expect  that  when 
breakthrough  technologies  or  innovations  have  been  declared,  such  as  in  a  refereed 
conference  paper  or  publication  in  an  educational  computing  journal,  the  opportunity 
exists  for  other  community  members  to  be  able  to  access,  review,  or  try  out  the 
software  to  assess  and  demonstrate  its  capabilities.  Furthermore,  there  appears  to 
be  growing  antagonism  toward  commercial  software  vendors  (Blackboard  Inc., 
PeopleSoft,  Oracle)  whose  products  target  the  higher  education  computing  market 
(e.g.,  WebCT).  However,  higher  education  computing  software  is  intended  for 
routine  production  use  by  administrative  end-users  and  others,  and  not  research- 
grade  “proof  of  concept”  demonstration  or  prototype  systems  that  are  found  in 
academic  research  laboratories. 


7  For  information  about  OSS  projects,  events,  and  activities  in  this  community,  see 

http://www.sakaiproiect.org,  http://www.moodle.org,  http://www.uportal.org, 

http://www.fluidproiect.org,  http://www.kuali.org,  as  well  as  EDUCAUSE  (http://www.educause.edu/), 
a  non-profit  association  focusing  on  current  issues  in  information  technology  for  higher  education, 
including  OSS  development  and  OSS  policy  in  academia. 
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2.5.  Military  Computing 

Participants  in  this  community8  focus  on  the  development  and  deployment  of 
computing  systems  and  applications  that  support  secured  military  and  combat 
operations.  Although  information  on  specific  military  systems  may  be  limited,  there 
are  a  small  but  growing  number  of  sources  of  public  information  and  OSS  projects 
that  support  military  and  combat  operations.  Accordingly,  it  is  becoming  clear  that 
the  future  of  military  computing,  and  the  future  acquisition  of  software-intensive, 
mission-critical  systems  for  military  or  combat  applications  will  increasingly  rely  on 
OSS  [3,  18,  26,  44,  55,  60,  63,  65],  For  example,  the  U.S.  Army  relies  on  tactical 
command  and  control  systems  hosted  on  Linux  systems  that  support  Apache  Tomcat 
servers,  Jabber/XMPP  chat  services,  and  JBoss- based  Web  services  [26],  Other 
emerging  applications  are  being  developed  for  future  combat  systems,  enterprise 
systems  (the  U.S.  Department  of  Defense  is  the  world's  largest  enterprise,  with  more 
than  1  million  military  and  civilian  employees),  and  various  training  systems,  among 
others  [60,  63,  65],  The  development  of  software  systems  for  developing  simulators 
and  game-based  virtual  worlds  [36]  are  among  those  military  software  projects  that 
operate  publicly  as  a  “traditional”  OSS  project  that  employs  a  GPL  software  license, 
while  other  projects  operate  as  corporate  source  (i.e.,  OSS  projects  behind  the 
corporate  firewall)  or  community  source  projects,  much  like  those  identified  for 
higher  education  computing  [64], 

2.6.  Overall  Cross-community  Characteristics 

In  contrast  to  efforts  that  draw  attention  to  generally  one  (but  sometimes 
many)  open  source  development  project(s)  within  a  single  community  [e.g.,  1 1 , 42, 
43],  there  is  something  to  be  gained  by  examining  and  comparing  the  communities, 
processes,  and  practices  of  OSSD  in  different  communities.  This  may  help  clarify 


s  The  primary  source  of  information  about  OSS  projects  in  the  military  comes  from  the  cited 
references,  rather  than  from  publicly  accessible  Web  sites.  However,  there  are  a  few  Military  OSS 
projects  accessible  on  the  Web  such  as  the  Delta3D  game  engine  at  http://www.Delta3D.org,  used  to 
developed  military  training  simulations. 
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what  observations  may  be  specific  to  a  given  community  (e.g.,  GNU/Linux  projects), 
compared  to  those  that  span  multiple,  and  mostly  distinct  communities.  In  this  study, 
two  of  the  communities  are  primarily  oriented  to  develop  software  to  support 
scholarly  research  or  institutional  administration  (bioinformatics  and  higher  education 
computing)  with  rather  small  user  communities.  In  contrast,  the  other  three 
communities  are  oriented  primarily  towards  software  development  efforts  that  may 
replace/create  commercially  viable  systems  that  are  used  by  large  end-user 
communities.  Thus,  there  is  a  sample  space  that  allows  comparison  of  different 
kinds. 


Each  of  these  highlighted  items  point  to  the  public  availability  of  data  that  can 
be  collected,  analyzed,  and  re-represented  within  narrative  ethnographies  [20,  29], 
computational  process  models  [37,  48,  57],  or  for  quantitative  studies  [21, 35], 
Significant  examples  of  each  kind  of  data  have  been  collected  and  analyzed  as  part 
of  this  ongoing  study.  This  paper  includes  a  number  of  OSSD  artifacts  as  data 
exhibits  that  empirically  ground  our  analysis.  These  artifacts  serve  to  document  the 
social  actions  and  technical  practices  that  facilitate  and  constrain  OSSD  processes 
[13,  14,  25,  53,  56],  Subsequently,  we  turn  to  review  what  requirements  engineering 
is  about,  in  order  to  establish  how  the  process  of  developing  OSS  system 
requirements  is  similar  or  different  than  is  common  to  traditional  software 
engineering  and  information  system  development  practices. 
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3.  Informalisms  for  Describing  OSS  Requirements 


The  functional  and  non-functional  requirements  for  OSS  systems  are  elicited, 
analyzed,  specified,  validated,  and  managed  through  a  variety  of  Web-based 
artifacts.  These  descriptive  documents  can  be  treated  as  software  informalisms. 
Software  informalisms  [49]  are  the  information  resources  and  artifacts  that 
participants  use  to  describe,  proscribe,  or  prescribe  what's  happening  in  a  OSSD 
project.  They  are  informal  narrative  resources  codified  in  lean  descriptions  [cf.  66] 
that  coalesce  into  online  document  genres  (following  [32,  59])  that  are  comparatively 
easy  to  use,  and  publicly  accessible  to  those  who  want  to  join  the  project,  or  just 
browse  around.  In  earlier  work,  Scacchi  [49]  demonstrates  how  software 
informalisms  can  take  the  place  of  formalisms,  like  “requirement  specifications”  or 
software  design  notations  which  are  documentary  artifacts  seen  as  necessary  to 
develop  high  quality  software  according  to  the  software  engineering  community  [5,  9, 
23,  ,  40],  Yet  these  software  informalisms  often  capture  the  detailed  rationale, 
contextualized  discourse,  and  debates  for  why  changes  were  made  in  particular 
development  activities,  artifacts,  or  source  code  files.  Nonetheless,  the  contents 
these  informalisms  embody  require  extensive  review  and  comprehension  by  a 
developer  before  contributions  can  be  made  [cf.  33],  Finally,  the  choice  to  designate 
these  descriptions  as  informalisms9  is  to  draw  a  distinction  between  how  the 
requirements  of  OSS  systems  are  described,  in  contrast  to  the  recommended  use  of 
formal,  logic-based  requirements  notations  (“formalisms”)  that  are  advocated  in 
traditional  approaches  [cf.  5,  9,  23,  ,  40], 

In  OSSD  projects,  software  informalisms  are  the  preferred  scheme  for 
describing  or  implicitly  representing  OSS  requirements.  There  is  no  explicit  objective 


9  As  Goguen  [19]  observes,  formalisms  are  not  limited  to  those  based  on  a  mathematical  logic 
or  state  transition  semantics,  but  can  include  descriptive  schemes  that  are  formed  from  structured  or 
semi-structured  narratives,  such  as  those  employed  in  Software  Requirements  Specifications 
documents. 
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or  effort  to  treat  these  informalisms  as  "informal  software  requirements"  that  should 
be  refined  into  formal  requirements  [8,  23,  30]  within  any  of  these  communities. 
Accordingly,  each  of  the  available  types  of  software  requirements  informalisms  have 
been  found  in  one  or  more  of  the  five  communities  in  this  study.  Along  the  way,  we 
seek  to  identify  some  of  the  relations  that  link  them  together  into  more 
comprehensive  stories,  storylines,  or  intersecting  story  fragments  that  help  convey 
as  well  as  embody  the  requirements  of  an  OSS  system.  Knowledge  about  who  is 
doing  what,  where,  when,  why,  and  how  is  captured  in  different  or  multiple 
informalisms. 

Two  dozen  types  of  software  informalisms  can  be  identified,  and  each  has 
sub-types  that  can  be  identified.  Those  presented  here  are  members  of  the  set  of 
software  informalisms  that  are  being  used  by  different  OSSD  projects.  Each  OSSD 
project  usually  employs  only  a  subset  as  its  informal  document  ecology  [cf.  32,  59] 
that  meets  their  interests  or  needs.  There  are  no  guidelines  for  which  informalisms  to 
use  for  what,  only  observed  practices  that  recur  across  OSSD  projects.  Thus  it  is 
pre-mature  and  perhaps  inappropriate  to  seek  to  further  organize  these  informalisms 
into  a  classification  or  taxonomic  scheme  whose  purpose  is  to  prescribe  when  or 
where  best  to  use  one  or  another.  Subsequently,  they  are  presented  here  as  an 
unordered  list  since  to  do  so  otherwise  would  transform  this  analysis  from  empirically 
ground,  interpretative  descriptions  into  untested,  hypothetical  prescriptions  [cf.  28, 
61]. 


The  most  common  informalisms  used  in  OSSD  projects  include  (i) 
communications  and  messages  within  project  Email  [66],  (ii)  threaded  message 
discussion  forums  (see  Exhibit  1),  bulletin  boards,  or  group  blogs,  (iii)  news  postings, 
and  (iv)  instant  messaging  or  Internet  relay  chat.  These  enable  developers  and 
users  to  converse  with  one  another  in  a  lightweight,  semi-structured  manner,  and 
now  use  of  these  tools  is  global  across  applications  domains  and  cultures.  As  such, 
the  discourse  captured  in  these  tools  is  a  frequent  source  of  OSS  requirements.  A 
handful  of  OSSD  projects  have  found  that  summarizing  these  communications  into 
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(v)  project  digests  [14]  helps  provide  an  overview  of  major  development  activities, 
problems,  goals,  or  debates.  These  project  digests  represent  multi-participant 
summaries  that  record  and  hyperlink  the  rationale  accounting  for  focal  project 
activities,  development  problems,  current  software  quality  status,  and  desired 
software  functionality.  Project  digests  (which  sometimes  are  identified  as  “kernel 
cousins”)  record  the  discussion,  debate,  consideration  of  alternatives,  code  patches 
and  initial  operational/test  results  drawn  from  discussion  forums,  online  chat 
transcripts,  and  related  online  artifacts  [cf.  14].  Exhibit  I10  provides  an  example  of  a 
project  digest  from  the  GNUe  electronic  business  software  project. 

As  OSS  developers  and  user  employ  these  informalisms,  they  have  been 
found  to  also  serve  as  carriers  of  technical  beliefs  and  debates  over  desirable 
software  features,  social  values  (e.g.,  reciprocity,  freedom  of  choice,  freedom  of 
expression),  project  community  norms,  as  well  as  affiliation  with  the  global  OSS 
social  movement  [12,  13,  53], 


io  Each  exhibit  appears  as  a  screenshot  of  a  Web  browsing  session.  It  includes  contextual 
information  seen  in  a  more  complete  display  view,  as  is  common  in  virtual  ethnographic  studies  [cf. 
20,  53,  57], 
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3. 26  Jun  Object  IDs  used  in  GNUe  where  there  is  no  primary  key 

4. 28  Jun  -  29  Jun  Problem  with  dropdowns  validation  fixed 

5. 29  Jun  -  6  Jul  Displaying  grids  in  GNUe  Forms  with  wx  2.6 

6. 6  Jul  Current  status  of  GNUe  Reports 


Introduction 

This  newsletter  mainly  covers  the  the  #gnuenterprise  IRC  channel,  with  occasional  coverage  of  the  three  main 
mailing  lists  (gnue-announce,  gnue  and  gnue-dev)  for  the  GNU  Enterprise  project. 


1.  Further  trouble-shooting  with  the  wx  2.6  drivers 

20  Jun  -  21  Jun  Archive  Link:  "HRC1  20  Jun  2006" 

Summary  By  Peter  Sullivan 
Topics:  Forms.  Common 

People:  Rcinhard  Muller.  .Tames  Thompson.  Johannes  Vetter.  Peter  Sullivan 

Further  to  Issue  #117.  Section  #2  (22  May  :  Layout  in  GNUe  Forms  with  wx  2.6  driver) ,  Reinhard  Muller 
(reinhard)  suggested  to  James  Thompson  (jamest)  "if  you  are  bored,  you  can  try  again  the  wx26  uidriver" 
,  as  Johannes  Vetter  (johannesV)  had  done  "some  massive  changes  and  it  might  be  that  your  issues  with 
fseking  up  the  boxes  are  solved "  .  James  said  that,  although  he  was  busy,  "i  really  need  to  get  that  tested, 
as  the  dropdown  box  issues  in  2.4  are  preventing  some  selections  from  being  allowed "  .  So  he  was  keen 
to  have  a  version  of  GNUe  Forms  that  worked  with  the  user  interface  driver  for  wx  2.6  as  soon  as  possible. 

Trying  Johannes'  new  code  for  GNUe  Forms  with  his  existing  GNUe  Forms  Definitions,  James  found 
problems  -  "none  of  which  are  due  to  anything  wrong  with  what  you've  done  -  it's  all  in  my  forms"  , 
where  he  had  been  relying  on  'features'  (such  as  overlapping  text  boxes)  that  Johannes  had  treated  as  bugs' 
and  now  fixed.  Johannes  confirmed  that  "overlaping  is  now  being  checked  ...  not  only  for  boxes  but  for 
all  widgets"  .  He  added,  "if  you  click  the  detail-button  you'll  see  the  offending  line  in  your  XML-File  - 
this  makes  debuging"  a  GNUe  Form  Definition  (gfd)  "a  lot  easier"  .  James  reported  that  all  five  of  his 
existing  GNUe  Form  Definitions  were  not  working  with  the  new  code  -  but  "i  would  still  imagine  it's 
something  funky  I'm  doing  in  the  form"  rather  than  a  problem  with  Johannes'  code.  He  noted  that,  on  the 
last  one,  the  problem  that  he  had  been  having  with  the  dropdown  menu  had  been  fixed,  but  the  form  now 
"aborts  on  query"  . 

(ed.  [Peter  Sullivan]  Note  that  the  lack  of  any  guarantees  on  backward  comparability,  even  with  'features'/'bugs'  is  one  of  the  reasons 
why  GNUe  Forms  remains  at  a  version  number  below  1 .0  as  of  time  of  writing,  as  discussed  further  in  Issue  #112.  Section  #4 
(13  Apr  :  Forms  approaching  version  1.0?) . ) 

Done 


Exhibit  1:  A  project  digest  that  summarizes  multiple  messages  including  those 
hyperlinked  (indicated  by  highlighted  and  underlined  text  fonts)  to  their  originating 
online  sources.  Source:  http://www.kerneltraffic.org/GNUe/latest.html,  July  2006. 

Other  common  informalisms  include  (vi)  scenarios  of  usage  as  linked  Web 
pages  or  screenshots,  (vii)  how-to  guides,  (viii)  to-do  lists,  (ix)  Frequently  Asked 
Questions,  and  other  itemized  lists,  and  (x)  project  Wikis,  as  well  as  (xi)  traditional 
system  documentation  and  (xii)  external  publications  [e.g.,  16,  17].  OSS  (xiii)  project 
property  licenses  (whether  to  assert  collective  ownership,  transfer  copyrights,  insure 
“copyleft,”  or  some  other  reciprocal  agreement)  are  documents  that  also  help  to 
define  what  software  or  related  project  content  are  protected  resources  that  can 
subsequently  be  shared,  examined,  modified,  and  redistributed. 
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Finally,  (xiv)  open  software  architecture  diagrams,  (xv)  intra-application 
functionality  realized  via  scripting  languages  like  Perl  and  PhP,  and  the  ability  to 
either  (xvi)  incorporate  externally  developed  software  modules  or  “plug-ins”,  or  (xvii) 
integrate  software  modules  from  other  OSSD  efforts,  are  all  resources  that  are  used 
informally,  where  or  when  needed  according  to  the  interests  or  actions  of  project 
participants. 

All  of  the  software  informalisms  are  found  or  accessed  from  (xix)  project 
related  Web  sites  or  portals.  These  Web  environments  are  where  most  OSS 
software  informalisms  can  be  found,  accessed,  studied,  modified,  and  redistributed 
[49], 


A  Web  presence  helps  make  visible  the  project's  information  infrastructure 
and  the  array  of  information  resources  that  populate  it.  These  include  OSSD  multi¬ 
project  Web  sites  (e.g.,  SourgeForge.net,  Savanah.org,  Freshment.org,  Tigris.org, 
Apache.org,  Mozilla.org),  community  software  Web  sites  (PhP-Nuke.org),  and 
project-specific  Web  sites  (e.g.,  www.GNUenterprise.org),  as  well  as  (xx)  embedded 
project  source  code  Webs  (directories),  (xxi)  project  repositories  (CVS  [16]),  and 
(xxii)  software  bug  reports  and  (xxiii)  issue  tracking  data  base  like  Bugzilla  [45, 
http://www.buqzilla.0rg/1.  Last,  giving  the  growing  global  interest  in  online  social 
networking,  it  not  surprising  to  find  increased  attention  to  documenting  various  kinds 
of  social  gatherings  and  meetings  using  (xxiv)  social  media  Web  sites  (e.g, 

YouTube,  Flickr,  MySpace,  etc.)  where  OSS  developers,  users,  and  interested 
others  come  together  to  discuss,  debate,  or  work  on  OSS  projects,  and  to  use  these 
online  media  to  record,  and  publish  photographs/videos  that  establish  group  identity 
and  affiliation  with  different  OSS  projects. 


Together,  these  two  dozen  types  of  software  informalisms  constitute  a 
substantial  yet  continually  evolving  web  of  informal,  semi-structured,  or  processable 
information  resources  that  capture,  organize,  and  distribute  knowledge  that  embody 
the  requirements  for  an  OSSD  project.  This  web  results  from  the  hyperlinking  and 
cross-referencing  that  interrelate  the  contents  of  different  informalisms  together. 
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Subsequently,  these  OSS  informalisms  are  produced,  used,  consumed,  or  reused 
within  and  across  OSSD  projects.  They  also  serve  to  act  as  both  a  distributed  virtual 
repository  of  OSS  project  assets,  as  well  as  the  continually  adapted  distributed 
knowledge  base  through  which  project  participants  evolve  what  they  know  about  the 
software  systems  they  develop  and  use  (cf.  [38]). 

Overall,  it  appears  that  none  of  these  software  informalisms  would  defy  an 
effort  to  formalize  them  in  some  mathematical  logic  or  analytically  rigorous  notation. 
Nonetheless,  in  the  three  of  the  five  software  communities  examined  in  this  study, 
there  is  no  perceived  requirement  for  such  formalization  (except  for  higher  education 
computing  and  military  computing),  as  the  basis  to  improve  the  quality,  usability,  or 
cost-effectiveness  of  the  OSS  systems.  If  formalization  of  these  documentary 
software  informalisms  has  demonstrable  benefit  to  members  of  these  communities, 
beyond  what  they  already  realize  from  current  practices,  these  benefits  have  yet  to 
be  articulated  in  the  discourse  that  pervades  each  community.  However,  in  contrast, 
the  higher  education  and  military  communities  do  traditionally  employ  and  develop 
formal  requirements  specification  documents  in  order  to  coordinate  and  guide 
development  of  their  respective  “community  source”  software  projects.  Thus,  we 
examine  and  compare  these  requirements  development  practices  across  all  five 
communities  so  as  to  surface  similarities,  differences,  and  their  consequences. 
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4.  OSS  Processes  for  Developing  Requirements 


In  contrast  to  the  world  of  classic  software  engineering,  OSSD  communities 
do  not  seem  to  readily  adopt  or  practice  modern  software  engineering  or 
requirements  engineering  processes.  Perhaps  this  is  no  surprise.  If  the  history  of 
software  engineering  were  to  reveal  that  one  of  the  driving  forces  for  capture  and 
formalize  software  requirements  was  to  support  the  needs  of  procurement  and 
acquisition  officials  (i.e.,  not  actual  users  of  the  resulting  software)  who  want  to  be 
sure  they  know  what  some  future  software  system  is  suppose  to  do  once  delivered, 
then  requirements  (documents)  serve  as  the  basis  for  software  development 
contracts,  delivery,  and  payment  schedules.  Software  requirements  are  traditionally 
understood  to  serve  a  role  in  the  development  of  proposed  systems  prior  to  their 
development  [cf.  5],  rather  than  for  software  systems  that  continuously  emerge  from 
networks  of  socio-technical  interactions  across  a  diverse  ecosystem  of  users, 
developers,  and  other  extant  software  systems  [51,  53,  61],  However,  OSS 
communities  do  develop  software  that  is  extremely  valuable,  generally  reliable,  often 
trustworthy,  and  readily  used  within  its  associated  user  community.  So,  what 
processes  or  practices  are  being  used  to  develop  the  requirements  for  OSS 
systems? 

We  have  found  many  types  of  software  requirements  activities  being 
employed  within  or  across  the  five  communities.  However,  what  we  have  found  in 
OSSD  projects  is  different  from  common  prescriptions  for  requirements  engineering 
processes  that  seem  to  embraced  in  varying  degrees  by  the  higher  education  and 
military  community  source  projects.  The  following  subsections  present  six  kinds  of 
OSS  requirements  activities  and  associated  artifacts  that  are  compared  with  those 
traditional  to  software  requirements  engineering. 
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4.1.  Informal  Post-hoc  Assertion  of  OSS  Requirements  vs. 
Requirements  Elicitation 

It  appears  that  OSS  requirements  are  articulated  in  a  number  of  ways  that  are 
ultimately  expressed,  represented,  or  depicted  on  the  Web.  On  closer  examination, 
requirements  for  OSS  can  appear  or  be  implied  within  an  email  message  or  within  a 
discussion  thread  that  is  captured  and/or  posted  on  a  Web  site  for  open  review, 
elaboration,  refutation,  or  refinement.  Consider  the  following  example  found  on  the 
Web  site  for  the  Avogardo  molecular  editor  tool  (http://avoqadro.openmolecules.net) 
in  the  bioinformatics  community.  This  example  displayed  in  Exhibit  2  reveals  the 
specification  “We  should  use  platform  libraries  when  present.  So  for  KDE,  if  the 
kdelibs  are  present,  we  should  use  them.”  As  noted  earlier,  KDE  is  an  Internet 
infrastructure  community  project. 
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We  should  use  platform  libraries  when  present.  So  for  KDE,  if  the  kdelibs 
are  present,  we  should  use  them.  This  gives  us  full  integration  of  the  KDE 
open/save  dialog  etc.  -  not  just  the  Qt  one. 

After  all,  we  do  the  same  thing  on  Windows  and  Mac:  we  use  the  native 
dialogs  and  widgets.  So  KDE  should  get  the  same  treatment. 


«C 


Exhibit  2.  A  sample  of  an  asserted  requirement  to  use  the  kdelibs  platform  libraries. 

Source: 

http://sourceforqe. net/tracker/index. php?func=detail&aid=1 851 183&qroup  id=1 6531 

0&atid=835080,  June  2008. 


These  capabilities  (appearing  near  the  bottom  of  Exhibit  2)  highlight  implied 
requirements  for  the  need  or  desirability  of  full  integration  of  the  Avogadro  editor  with 
the  KDE  functional  command  dialog  system.  These  requirements  are  simply 
asserted  without  reference  to  other  documents,  standards,  or  end-user  focus 
groups — they  are  requirements  because  some  developers  wanted  these  capabilities. 


vRABwm*  per  scif.vr/AA, 
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Perhaps  it  is  more  useful  to  define  OSS  requirements  as  asserted  system 
capabilities.  These  capabilities  are  post  hoc  requirements  characterizing  a 
functional  capability  that  has  already  been  implemented,  either  in  the  system  at 
hand,  or  by  reference  to  some  other  related  system  that  already  exists.  Based  on 
observations  and  analyses  presented  here  and  elsewhere  [12,  14,  24,  25,  49,  50, 
53],  it  appears  that  concerned  OSS  developers  assert  and  justify  software  system 
capabilities  they  support  through  their  provision  of  the  required  coding  effort  to  make 
these  capabilities  operational,  or  to  modification  of  some  existing  capability  which 
may  be  perceived  as  limited  or  sometimes  deficient.  Senior  members  or  core 
developers  in  the  community  then  vote  or  agree  through  discussion  to  include  the 
asserted  capability  into  the  system’s  feature  set  [15],  or  at  least,  not  to  object  to  their 
inclusion.  The  historical  record  of  their  discourse  and  negotiation  may  be  there, 
within  the  email  or  discussion  forum  archive,  to  document  who  required  what,  where, 
when,  why,  and  how.  However,  once  asserted,  there  is  generally  no  further  effort 
apparent  to  document,  formalize,  or  substantiate  such  a  capability  as  a  system 
requirement.  Asserted  capabilities  then  become  taken-for-granted  requirements  that 
are  can  be  labeled  or  treated  as  obvious  to  those  familiar  with  the  system's 
development. 

Another  example  reveals  a  different  kind  required  OSSD  capability.  This  case 
displayed  in  Exhibit  3,  finds  a  “mission”  document  that  conveys  a  non-functional 
requirement  for  both  community  development  and  community  software  development 
in  the  bottom  third  of  the  exhibit.  This  can  be  read  as  a  non-functional  requirement 
for  the  system’s  developers  to  embrace  community  software  development  as  the 
process  to  develop  and  evolve  the  ArgoUML  system,  rather  than  through  a  process 
that  relies  on  the  use  of  system  models  represented  as  UML  diagrams. 

Perhaps  community  software  development,  and  by  extension,  community 
development,  are  recognized  as  socio-technical  capabilities  that  are  important  to  the 
development  and  success  of  this  system.  Regular  practice  of  such  capabilities  may 
also  be  a  method  for  improving  system  quality  and  reliability  that  can  be  compared 
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to  functional  capabilities  of  existing  software  engineering  tools  and  techniques  that 
seem  to  primarily  focus  on  technical  or  formal  analysis  of  software  development 
artifacts  as  the  primary  way  to  improve  quality  and  reliability. 

The  next  example  reveals  yet  another  kind  of  elicitation  found  in  the 
Internet/Web  infrastructure  community.  In  Exhibit  4,  we  see  an  overview  of  the 
MONO  project.  Here  we  see  multiple  statements  for  would-be  software 
component/class  owners  to  sign-up  and  commit  to  developing  the  required  ideas, 
run-time,  (object  service)  classes,  and  projects  [cf.  25],  These  are  non-functional 
requirements  for  people  to  volunteer  to  participate  in  community  software 
development,  in  a  manner  perhaps  compatible  with  that  portrayed  in  Exhibit  3. 
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2  Tigris.org:  Open  Source  Software  Engineering  -  Mozilla  Firefox 
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Tigris.org  Community  Scope 


►  Tigris.org  is  a  mid-sized  open  source  community  focused  on 
building  better  tools  for  collaborative  software  development, 

►  You  will  not  find  thousands  of  unrelated  projects  here:  every 
project  fits  into  the  Tigris  mission. 

►  You  will  not  find  dead  projects  here:  every  project  is  welcomed 
into  the  community  with  a  commitment  to  see  it  through  and 
active  developers  cycle  among  related  projects. 

►  Tigris.org  is  hosted  by  CollabNet,  but  the  Tigris  mission  is  one 
for  the  entire  open  source  movement  and  one  that  has  attracted 
senior  open  source  developers  from  many  organizations. 


The  Tigris  Mission:  Building  Open  Source  Software 
Engineering  Tools 


Tigris.org  provides  information  resources  for  software 
_ i  engineering  professionals  and  students,  and  a  home 

#for  open  source  software  engineering  tool  projects. 

Software  engineering  practices  are  key  to  any  large 
development  project.  Unfortunately,  software 
engineering  tools  and  methods  are  not  widely  used  today.  Even 
after  over  30  years  as  a  engineering  profession,  most  software 
developers  still  use  few  software  engineering  tools.  Some  of  the 
reasons  are  that  tools  are  expensive  and  hard  to  learn  and  use, 
also  many  developers  have  never  seen  software  engineering  tools 
used  effectively. 

The  open  source  software  development  movement  has  produced  a 
number  of  very  powerful  and  useful  software  development  tools, 
but  it  has  also  evolved  a  software  development  process  that 
works  well  under  conditions  where  normal  development  processes 
fail.  The  software  engineering  field  can  learn  much  from  the  way 
that  successful  open  source  projects  gather  requirements,  make 
design  decisions,  achieve  quality,  and  support  users.  Open  source 
projects  are  also  a  great  for  developers  to  keep  their  skills  current 
and  plug  into  a  growing  base  of  shared  experience  for  everyone  in 
the  field. 
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Exhibit  3.  An  OSS  mission  statement  encouraging  both  the  development  of 
software  for  the  community  and  development  of  the  community.  Source: 
http://www.tiqris.org,  June  2008. 

The  systems  in  Exhibit  3  must  also  be  considered  early  in  their  overall 
development  or  maturity,  because  it  calls  for  functional  capabilities  that  are  needed 
to  help  make  the  desired  software  functionality  sufficiently  complete  for  future  usage. 
However,  these  yet  “Todo”  software  implementation  tasks  signal  to  prospective  OSS 
developers,  who  may  want  to  join  a  project,  as  to  what  kinds  of  new  software 
functionalities  are  desired,  and  thus  telegraph  a  possible  pathway  for  how  to  become 
a  key  contributor  within  a  large,  established  OSSD  project  [25]  by  developing  a 
proposed  software  system  component  or  function  that  some  core  developer  desires. 
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Mono  Tasks 

From  time  to  time  people  that  want  to  contribute  to 
Mono  ask  on  the  mailing  list  what  they  can  help 
with.  The  generic  answer  is  always: 

♦  Write  documentation. 

♦  Write  regression  tests 

♦  Complete  the  implementations  of  the  class 
libraries. 

♦  Help  fix  the  bugs  filed  in  our  bugzilla 
database. 

The  proposed  tasks  are  very  important  for  the  Mono  project  and  are  suitable  for  people  that  can  dedicate 
even  just  an  hour  per  week  to  contribute.  But  some  people  may  need  something  more  focused  to  work  on, 
such  as  students  that  want  to  do  a  thesis  on  their  contribution  to  Mono.  For  such  people  (and  also  for 
professors  who  want  ideas  for  thesis  regarding  JIT  or  VM  technologies),  here  is  a  list  of  tasks  that  need 
attention. 

The  estimated  time  to  complete  any  of  the  tasks  is  between  1  week  to  several  months  to  accomodate  for 
different  hacking  possibilities. 

Note  on  the  time  estimates:  they  are  very  rough  estimates,  a  smart  and  dedicated  hacker  can  complete  the 
tasks  in  half  of  the  minimum  time,  a  part-time  hacker  that  also  has  a  social  life  can  take  more  than  double  the 
max  time,  but  there's  nothing  to  worry  as  long  as  progress  is  being  done. 

If  some  people  (or  group  of  people)  want  to  take  on  a  task,  they  should  write  to  the  mono-devel  mailing  list 
and  in  the  relative  bugzilla  bug  report.  Discussions  about  howto  implement  a  feature  or  additional  information 
on  the  task  should  be  mailed  to  the  list  or  in  the  bugzilla  report  as  well  so  that  people  can  keep  informed  on 
the  progress  or  have  the  information  needed  to  start  contributing.  Mono  is  an  excellent  platform  for  research 
on  JITs,  virtual  machines  and  specifically  the  CLR  because  it  provides  an  advanced  free  software 
implementation  that  can  be  used  as  a  basis  for  more  optimizations,  new  approaches  to  problems  and  new 
features. 

There  are  different  areas  of  interest  where  high-level  contributions  can  be  made: 

♦  JIT  compiler:  tasks  can  be:  adding  more  optimizations,  reducing  compile  time,  porting  to  different 
architectures. 

♦  AOT  compiler:  optimizing  the  compiler  output  and  the  AOT  loader,  better  support  for  multiple 
application  domains. 

♦  VM  runtime:optimizing  the  runtime  data  structures,  experimenting  with  different  garbage  collectors, 
integration  with  different  component  models. 

♦  Class  library:many  opportunities  in  the  implementation  of  regular  expressions,  Xml  related 
technologies  (XPath,  XLST,  etc). 

♦  Compilers:writing  compilers,  interpreters  and  runtimes  for  langauges  so  that  they  run  on  the  CLR 
(using  Reflection. Emit  support,  for  example). 

Happy  hacking! 
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Exhibit  4:  A  non-functional  requirement  identifying  a  need  for  volunteers  to  become 
owners  for  yet  to  be  developed  software  components  whose  functional  requirements 
are  still  somewhat  open  and  yet  to  be  determined.  Source:  http://www.mono- 

proiect.com/Todo,  June  2008. 

Thus,  in  understanding  how  the  capabilities  and  requirements  of  OSS 
systems  are  elicited,  we  find  evidence  for  elicitation  of  volunteers  to  come  forward  to 
participate  in  community  software  development  by  proposing  new  software 
development  projects,  but  only  those  that  are  compatible  with  the  OSS  engineering 
mission  for  the  Tigris.org  community. 
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We  also  observe  the  assertion  of  requirements  that  simply  appear  to  exist 
without  question  or  without  trace  to  a  point  of  origination,  rather  than  somehow  being 
elicited  from  stakeholders,  customers,  or  prospective  end-users  of  OSS  systems.  As 
previously  noted,  we  have  not  yet  found  evidence  or  data  to  indicate  the  occurrence 
or  documentation  of  a  requirements  elicitation  effort  arising  in  a  traditional  OSSD 
project.  However,  finding  such  evidence  would  not  invalidate  the  other  observations; 
instead,  it  would  point  to  a  need  to  broaden  the  scope  of  how  software  requirements 
are  captured  or  recorded.  For  example,  community  source  projects  found  in  the 
higher  education  community  seek  to  span  OSSD  practices  with  traditional  software 
engineering  practices,  which  results  in  hybrid  software  development  and  software 
requirements  practices  that  do  not  seem  to  fully  realize  the  practices  (or  benefits)  of 
OSS  engineering  projects  like  those  found  at  Tigris.org.  Early  experiences  with  such 
a  hybrid  scheme  suggest  that  successful  software  production  may  not  directly  follow 
[47], 


4.2.  Requirements  Reading,  Sense-making,  and  Accountability 
vs.  Requirements  Analysis 

Software  requirements  analysis  helps  identify  what  problems  a  software 
system  is  suppose  to  address  and  why,  while  requirements  specifications  identify  a 
mapping  of  user  problems  to  system  based  solutions.  In  OSSD,  how  does 
requirements  analysis  occur,  and  where  and  how  are  requirements  specifications 
described?  Though  requirements  analysis  and  specification  are  interrelated 
activities,  rather  than  distinct  stages,  we  first  consider  examining  how  OSS 
requirements  are  analyzed.  In  Exhibit  5  from  the  networked  game  community  for  the 
computer  game  Unreal  Tournament  (aka,  UT3),  it  seems  that  game  mod 
developers  are  encouraged  to  produce  multi-version,  continuously  improving  game 
mods,  so  that  they  can  subsequently  be  recognized  as  professional  game 
developers.  Thus,  OSS  developers  learn  that  achieving  enhanced  social  status 
requires  development  of  new  software  functions  (mods)  that  improve  across 
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versions. 


In  seeking  to  analyze  what  is  needed  to  more  capably  develop  UT3  game 
mods,  a  game  developer  may  seek  additional  information  from  other  sources  to 
determine  how  best  to  satisfy  the  challenge  of  developing  a  viable  game  mod.  This 
in  turn  may  lead  one  to  discover  and  review  secondary  information  sources,  such  as 
that  shown  in  Exhibit  6.  This  exhibit  points  to  still  other  Web-based  information 
sources  revealing  both  technical  and  social  challenges  that  must  be  addressed  to 
successfully  develop  a  viable  game  mod. 
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Exhibit  5.  An  asserted  capability  (in  the  center)  that  invites  would-be  OSS  game 
developers  to  make  UT3  game  mods,  including  improved  versions,  of  whatever  kind 
they  require  among  the  various  types  of  available  extensions  so  they  may  “get 
professional  status,”  and  possibly  win  money  or  other  contest  prizes.  Source: 
http://www.ut3moddinq.com/,  June  2008. 
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UnrealWiki:  Making  Mods 
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The  Layman's  Guide  to  Making  Mods 

If  you  are  thinking  about  making  a  mod  (for  any  game)  and  are  not  sure  what  you  need  to  know,  how  to  go 
about  it,  or  simply  want  to  avoid  the  most  obvious  mistakes  then  read  on.  The  pages  linked  to  below  contain 
some  excellent  advice,  and  possibly  comments  on  stuff  that  hadn't  occured  to  you. 

•  /Mv  Team  Your  T earn  -  Introduction  and  disclaimer  for  all  those,  What's  all  this  my  team  your  team 
crap?"  readers. 

•  /Why  Are  You  Making  A  Mod  -  Sometimes  the  reason  a  mod  fails  is  the  reason  you  started  it  in  the  first 
place. 

•  /Building  a  Team  -  Building  up  your  mod  team. 

•  /Despotism  Or  Communism  -  Some  thoughts  on  team  structure. 

•  /Working  as  a  Team  -  The  day  to  day  life  of  a  team. 

•  /Asset  Management  -  How  to  manage  the  assets  of  your  mod  (code,  textures,  models,  etc). 

•  /Distributed  Development-  Find  out  how  hard  and  unpleasant  distributed  development  can  be. 

•  /Effective  Testing  -  How  to  get  the  most  out  of  testing  your  mod. 

•  Releasing  A  Mod 

•  /Supporting  Your  Mod  -  Easing  the  burden  of  mod  support. 

•  /Mod  Death  -  What  happens  when  a  mod  or  mod  team  self  destruct  and  how  to  cope. 


Mapping  Topics 
Mapping  Lessons 
UnrealEd  Interface 

UnrealScript  Topics 
UnrealScript  Lessons 
Making  Mods 
Class  Tree 

Modeling  Topics 

Chongqing  Page 
Login 


Done 


Thoughts  on  Mod  Making 

Several  of  the  Unreal  Wiki's  contributors  have  experience  in  creating  successful  mods.  Reading  their 
accounts  of  their  work  and  their  advice  is  recommended. 

•  Mvchaeel/Mod  Startups  -  Making  your  idea  a  reality. 

•  Mvchaeel/Moddino  Etiquette  -  How  to  make  people  like  your  mod. 

•  Jb  -  an  analysis  of  the  ChaosUT  mod's  history 

•  Pialet/Finishina  Things  -  How  to  actually  finish  your  mods,  that  said  it’s  more  how  to  start  so  that  you 
can  finish. 

•  A  Bug's  Life 

•  GODZ  Inception  -  a  journal  of  how  GODZ  started. 

•  Making  Mods/General  Mod  Optimization  -  Common  mistakes  and  ignored  settings  which  often  lead  to 
lower  performance  -  and  how  to  fix/use  them. 


Exhibit  6:  Understanding  and  analyzing  what  you  need  to  know  and  do  in  order  to 
develop  a  game  mod.  Source:  http://wiki.beyondunreal.com/wiki/Makinq  Mods,  May 

2006. 

The  notion  that  requirements  for  OSS  system  are,  in  practice,  analyzed  via 
the  reading  of  technical  accounts  as  narratives,  together  with  making  sense  of  how 
such  readings  are  reconciled  with  one’s  prior  knowledge,  is  not  unique  to  the  game 
modding  software  community.  These  same  activities  can  and  do  occur  in  the  other 
three  communities.  If  one  reviews  the  functional  and  non-functional  requirements 
appearing  in  Exhibits  1-6,  it  is  possible  to  observe  that  none  of  the  descriptions 
appearing  in  these  exhibits  is  self-contained.  Instead,  each  requires  the  reader  (e.g., 
a  developer  within  the  community)  to  closely  or  casually  read  what  is  described, 
make  sense  of  it,  consult  other  materials  or  one’s  expertise,  and  trust  that  the 
description’s  author(s)  are  reliable  and  accountable  in  some  manner  for  the  OSS 
requirements  that  has  been  described  [19,  42],  Analyzing  OSS  requirements  entails 
little/no  automated  analysis,  formal  reasoning,  or  visual  animation  of  software 
requirements  specifications  prior  to  the  development  of  proposed  software 
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functionality  [cf.  5,  40],  Instead,  emphasis  focuses  on  understanding  what  has 
already  been  accomplished  in  existing,  operational  system  functionality,  as  well  as 
what  others  have  written  and  debated  about  it  in  different,  project-specific 
informalisms.  Subsequently,  participants  in  these  communities  are  able  to 
understand  what  the  functional  and  non-functional  requirements  are  in  ways  that  are 
sufficient  to  lead  to  the  ongoing  development  of  various  kinds  of  OSS  systems. 

4.3.  Continually  Emerging  Webs  of  Software  Discourse  vs. 
Requirements  Specification  and  Modeling 

If  the  requirements  for  OSS  systems  are  asserted  after  code-based 
implementation  rather  than  elicited  prior  to  development  of  proposed  system 
functionality,  how  are  these  OSS  requirements  specified  or  modeled?  In  traditional 
software  development  projects,  the  specification  of  requirements  may  be  a 
deliverable  required  by  contract.  In  most  OSSD  projects,  there  are  no  such 
contractual  obligations,  and  there  are  no  requirements  specification  documents.  In 
examining  data  from  the  five  communities,  of  which  Exhibits  1-6  are  instances,  it  is 
becoming  increasingly  apparent  that  OSS  capabilities  can  emerge  both  from  the 
experiences  of  community  participants  using  the  software,  as  well  as  through 
iterative  discussion  and  debate  rendered  in  email  and  discussion  forums.  These 
communication  messages  in  turn  give  rise  to  the  development  of  narrative 
descriptions  that  more  succinctly  specify  and  condense  into  a  web  of  discourse 
about  the  functional  and  non-functional  requirements  of  an  OSS  system.  This 
discourse  is  rendered  in  multiple,  dispersed  descriptions  that  can  be  found  in  email 
and  discussion  forum  archives,  on  Web  pages  that  populate  community  Web  sites, 
and  in  other  informal  software  descriptions  that  are  posted,  hyperlinked,  or  passively 
referenced  through  the  assumed  common  knowledge  that  community  participants 
expect  their  cohorts  to  possess.  In  this  way,  participating  OSS  developers  and  users 
collectively  develop  a  deep,  situated  understanding  of  the  capabilities  they  have 
realized  and  how  unrealized  needs  must  be  argued  for,  negotiated,  and  otherwise 
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be  found  to  be  obvious  to  the  developers  who  see  it  in  their  self-interest  to  get  them 
implemented. 

In  Exhibit  7  from  the  bioinformatics  community,  we  see  passing  reference  to 
the  implied  socio-technical  requirement  for  bioinformatics  scientists  to  program  and 
orchestrate  an  e-science  workflow  to  perform  their  research  computing  tasks.  Such 
workflows  are  needed  to  realize  a  multi-step  computational  process  that  can  be 
satisfied  through  an  e-science  tool/framework  like  Taverna  [cf.  22,  41].  To 
comprehend  and  recognize  what  the  requirements  for  bioinformatics  workflows  are 
in  order  to  determine  how  to  realize  some  bioinformatics  data  analysis  or  in  silico 
experiment,  community  members  who  develop  OSS  for  such  applications  will  often 
be  bioinformatics  scientists  (e.g.,  graduate  students  or  researchers  with  Ph.D. 
degrees),  and  rarely  would  be  simply  a  competent  software  engineering 
professional.  Consequently,  the  bioinformatics  scientists  that  develop  software  in 
this  community  do  not  need  to  recapitulate  any  software  system  requirement  of  the 
problem  domain  (e.g.,  microbiology).  Instead,  community  members  are  already 
assumed  to  have  mastery  over  such  topics  prior  to  software  development,  rather 
than  encountering  problems  in  their  understanding  of  microbiology  arising  from 
technical  problems  in  developing,  operation,  or  functional  enhancement  of 
bioinformatics  software.  Subsequently,  discussion  and  discourse  focuses  on  how  to 
use  and  extend  the  e-science  workflow  software  in  order  to  accomplish  the  scientific 
research  to  be  realized  through  a  computational  workflow  specification.  Thus,  a  web 
of  discourse  can  emerge  about  the  functional  requirement  for  specifying 
computational  workflows  that  can  be  supported  and  documented  by  the  software 
capabilities  of  an  OSS  workflow  modeling  tool  like  Traverna  [41],  rather  than  for 
specifying  the  functionality  of  the  tool. 
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Taverna  project  website 
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What  is  Taverna  about? 

The  best  way  to  understand  what  Taverna  is  about  and  what  it  could  potentially  do  for  you 
is  to  use  it,  however,  a  quick  read  of  the  background  information  section  might  be  useful  if 
you  are  not  familiar  with  the  idea  of  workflows  in  bioinformatics.  Effectively  Taverna  allows 
a  biologist  or  bioinformatician  with  limited  computing  background  and  limited  technical 
resources  and  support  to  construct  highly  complex  analyses  over  public  and  private  data 
and  computational  resources,  all  from  a  standard  PC,  UNIX  box  or  Apple  computer.  The 
screenshot  below  shows  the  workbench  in  action  running  an  example  workflow. 


Exhibit  7:  A  description  with  embedded  screenshot  example  of  the  Taverna  tool 
framework  for  bioinformatics  scientists  suggesting  why  and  how  to  develop 
workflows  for  computational  processes  needed  to  perform  a  complex  data  analysis 
or  in  silico  research  experiment  [41].  Source  http://taverna.sourceforce.net  June 

2008. 

Thus,  spanning  the  five  communities  and  the  seven  exhibits,  we  begin  to 
observe  that  the  requirements  for  OSS  are  specified  in  webs  of  discourse  that 
reference  or  link: 


email,  bboard  discussion  threads,  online  chat  transcripts  or  project 
digests, 

system  mission  statements, 

ideas  about  system  functionality  and  the  non-functional  need  for 
volunteer  developers  to  implement  the  functionality, 
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■  promotional  encouragement  to  specify  and  develop  whatever 
functionality  you  need,  which  might  also  help  you  get  a  new  job,  and 

■  scholarly  scientific  research  tools  and  publications  that  underscore  how 
the  requirements  of  bioinformatics  software  though  complex,  are 
understood  without  elaboration,  since  they  rely  on  prior  scientific 
knowledge  and  tradition  of  open  scientific  research. 

Each  of  these  modes  of  discourse,  as  well  as  their  Web-based  specification 
and  dissemination,  is  a  continually  emerging  source  of  OSS  requirements  from  new 
contributions,  new  contributors  or  participants,  new  ideas,  new  career  opportunities, 
and  new  research  publications. 

4.4.  Condensing  Discourse  that  Hardens  and  Concentrates 
System  Functionality  and  Community  Development  vs. 
Requirements  Validation 

Software  requirements  are  validated  with  respect  to  the  software’s 
implementation.  The  implemented  system  can  be  observed  to  demonstrate,  exhibit, 
or  be  tested  in  operation  to  validate  that  its  functional  behavior  conforms  to  its 
functional  requirements.  How  are  the  software  implementations  to  be  validated 
against  their  requirements  OSS  requirements  when  they  are  not  recorded  in  a  formal 
Software  Requirements  Specifications  document,  nor  are  these  requirements 
typically  cast  in  a  mathematical  logic,  algebraic,  or  state  transition-based  notational 
scheme? 

In  each  of  the  five  communities,  it  appears  that  the  requirements  for  OSS  are 
co-mingled  with  design,  implementation,  and  testing  descriptions  and  software 
artifacts,  as  well  as  with  user  manuals  and  usage  artifacts  (e.g.,  input  data,  program 
invocation  scripts).  Similarly,  the  requirements  are  spread  across  different  kinds  of 
artifacts  including  Web  pages,  sites,  hypertext  links,  source  code  directories, 
threaded  email  transcripts,  and  more.  In  each  community,  requirements  are  routinely 
described,  asserted,  or  implied  informally.  Yet  it  is  possible  to  observe  in  threaded 
email  discussions  that  community  participants  are  able  to  comprehend  and 
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condense  wide-ranging  software  requirements  into  succinct  descriptions  using  lean 
media  that  pushes  the  context  for  their  creation  into  the  background. 


Consider  the  next  example  found  on  the  Web  site  for  the  KDE  system 
(http://www.kde.org/),  within  the  Internet/Web  Infrastructure  community.  This 
example  displayed  in  Exhibit  8  reveals  asserted  capabilities  for  the  Qt3  subsystem 
within  KDE,  as  well  as  displaying  and  documenting  the  part  of  the  online  discourse 
that  justifies  and  explains  the  capabilities  of  the  Qt3  subsystem  in  a  manner  that 
concentrates  attention  to  processing  features  that  the  contributors  find  rationalizes 
the  Qt3  requirements. 
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Exhibit  8.  Asserted  requirements  and  condensed  justifications  producing  a 
hardened  rationale  for  the  KDE  software  subsystem  Qt3  expressed  through  an 
online  discourse.  Source:  http://dot.kde.org/996206041/.  July  2001. 

Goguen  [19]  suggests  the  metaphor  of  "concentrating  and  hardening  of 
requirements"  as  a  way  to  characterize  how  software  requirements  evolve  into  forms 
that  are  perceived  as  suitable  for  validation.  His  characterization  seems  to  quite 
closely  match  what  can  be  observed  in  the  development  of  requirements  for  OSS. 
We  find  that  requirements  validation  is  a  by-product,  rather  than  an  explicit  goal,  of 
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how  OSS  requirements  are  constituted,  described,  discussed,  cross-referenced,  and 
hyperlinked  to  other  informal  descriptions  of  system  and  its  implementations. 

4.5.  Global  access  to  OSS  Webs  vs.  Communicating 
Requirements 

One  distinguishing  feature  of  OSS  associated  with  each  of  the  five 
communities  is  that  their  requirements,  informal  as  they  are,  are  organized  and 
typically  stored  in  a  persistent  form  that  is  globally  accessible.  This  is  true  of 
community  Web  sites,  site  contents  and  hyperlinkage,  source  code  directories, 
threaded  email  and  other  online  discussion  forums,  descriptions  of  known  bugs  and 
desired  system  enhancements,  records  of  multiple  system  versions,  and  more. 
Persistence,  hypertext-style  organization  and  linkage,  and  global  access  to  OSS 
descriptions  appear  as  conditions  that  do  not  receive  much  attention  within  the 
classic  requirements  engineering  approaches,  with  few  exceptions  [8],  Yet,  each  of 
these  conditions  helps  in  the  communication  of  OSS  requirements.  These  conditions 
also  contribute  to  the  ability  of  community  participants  or  outsiders  looking  in  to  trace 
the  development  and  evolution  of  software  requirements  both  within  the  software 
development  descriptions,  as  well  as  across  community  participants.  This  enables 
observers  or  developers  to  navigationally  trace,  for  example,  a  web  of  different 
issues,  positions,  arguments,  policy  statements,  and  design  rationales  that  support 
(e.g.,  see  Exhibit  8)  or  challenge  the  viability  of  emerging  software  requirements  [cf. 
7,  34], 


Each  of  the  five  communities  also  communicates  community-oriented 
requirements.  These  non-functional  requirements  may  seem  similar  to  those  for 
enterprise  modeling  [40,  46],  However,  there  are  some  differences,  though  they  may 
be  minor.  First,  each  community  is  interested  in  sustaining  and  growing  the 
community  as  a  development  enterprise  [cf.  38],  Second,  each  community  is 
interested  in  sustaining  and  growing  the  community’s  OSS  artifacts,  descriptions, 
and  representations.  Third,  each  community  is  interested  in  updating  and  evolving 
the  community's  information  sharing  Web  sites.  In  recognition  of  these  community 
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requirements,  it  is  not  surprising  to  observe  the  emergence  of  commercial  efforts 
(e.g.,  SourceForge  and  CollabNet)  that  offer  community  support  systems  that  are 
intended  to  address  these  requirements,  such  as  is  used  in  projects  like  those  in 
Tigris.org,  or  even  the  Avogadro  project  in  the  Bioinformatics  community  see 
(Exhibits  2  and  3). 

4.6.  Identifying  a  Common  Foundation  for  the  Development  of 
OSS  Requirements 

Based  on  the  data  and  analysis  presented  above,  it  is  possible  to  begin  to 
identify  what  items,  practices,  or  capabilities  may  better  characterize  how 
requirements  for  OSS  are  developed  and  articulated.  This  centers  around  the 
preceding  OSS  requirements  processes  that  enable  the  emergent  creation,  usage, 
and  evolution  of  informal  software  descriptions  as  the  vehicle  for  developing  OSS 
requirements. 
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Understanding  OSS  Requirements 


First,  there  is  no  single  correct,  right,  or  best  way/method  for  constructing 
software  system  requirements.  The  requirements  engineering  approach  long 
advocated  by  the  software  engineering  and  software  requirements  community  does 
not  account  for  the  practice  nor  results  of  OSS  system,  project,  or  community 
requirements.  OSS  requirements  (and  subsequent  system  designs)  are  different. 
Thus,  given  the  apparent  success  of  sustained  exponential  growth  for  certain  OSS 
systems  [10,  52],  and  for  the  world-wide  deployment  of  OSSD  practices,  it  is  safe  to 
say  that  the  ongoing  development  of  OSS  systems  points  to  the  continuous 
development,  articulation,  adaptation,  and  reinvention  of  their  requirements  [cf.  50] 
as  capabilities  that  emerge  through  socio-technical  interactions  between  people, 
discursive  artifacts,  and  the  systems  they  use,  rather  than  as  needs  to  be  captured 
before  the  proposed  system  comes  into  use. 

Second,  the  traditional  virtues  of  high-quality  software  system  requirements, 
namely,  their  consistency,  completeness,  traceability,  and  internal  correctness  are 
not  so  valued  in  OSSD  projects.  OSSD  projects  focus  attention  and  practice  to  other 
virtues  that  emphasize  community  development  and  participation,  as  well  as  other 
socio-technical  concerns.  Thus,  as  with  the  prior  observation,  OSS  system 
requirements  are  different,  and  therefore  may  represent  an  alternative  paradigm  for 
how  to  develop  robust  systems  that  are  open  to  both  their  developers  and  users. 
Nonetheless,  there  are  many  examples  of  the  use  of  tools  and  techniques  for 
articulating  OSS  requirements  as  well  as  for  tracing  or  monitoring  their  development 
[cf.  46], 

Third,  OSS  developers  are  generally  also  end-users  of  the  systems  they 
develop.  Thus,  there  is  no  “us-them”  distinction  regarding  the  roles  of  developers 
and  end-users,  as  is  commonly  assumed  in  traditional  system  development 
practices.  Because  the  developers  are  also  end-users,  communication  gaps  or 
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misunderstandings  often  found  between  developers  and  end-users  are  typically 
minimized. 

Fourth,  OSS  requirements  tend  to  be  distributed  across  space,  time,  people, 
and  the  artifacts  that  interlink  them.  OSS  requirements  are  thus  decentralized — that 
is,  decentralized  requirements  that  co-exist  and  co-evolve  within  different  artifacts, 
online  conversations,  and  repositories,  as  well  as  within  the  continually  emerging 
interactions  and  collective  actions  of  OSSD  project  participants  and  surrounding 
project  social  world.  To  be  clear,  decentralized  requirements  are  not  the  same  as 
the  (centralized)  requirements  for  decentralized  systems  or  system  development 
efforts.  Traditional  software  engineering  and  system  development  projects  assume 
that  their  requirements  can  be  elicited,  captured,  analyzed,  and  managed  as 
centrally  controlled  resources  (or  documentation  artifacts)  within  a  centralized 
administrative  authority  that  adheres  to  contractual  requirements  and  employs  a 
centralized  requirements  artifact  repository — that  is,  centralized  requirements.  Once 
again,  OSS  projects  represent  an  alternative  paradigm  to  that  long  advocated  by 
software  engineering  and  software  requirements  engineering  community. 

Last,  given  that  OSS  developers  are  frequently  the  source  for  the 
requirements  they  realize  in  hindsight  (i.e. ,  what  they  have  successfully  implemented 
and  released  denote  what  was  required)  rather  than  in  foresight,  perhaps  it  is  better 
to  characterize  such  software  system  requirements  as  instead  “software  system 
capabilities”  (and  not  software  development  practices  associated  with  capability 
maturity  models).  She  or  he  who  codes  determines  what  the  requirements  will  be 
based  on  what  they  have  coded — the  open  source  code  frequently  appears  before 
there  is  some  online  discourse  that  specifies  how  and  why  it  was  done.  OSS 
developers  may  simply  tell  others  what  was  done,  whether  or  not  they  discussed 
and  debated  it  beforehand.  They  are  generally  under  no  contractual  obligation  to 
report  and  document  software  functionality  prior  to  its  coding  and  implementation. 
Subsequently,  OSS  capabilities  embody  requirements  that  have  been  found 
retrospectively  to  be  both  implementable  and  sustainable  across  releases.  Software 
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capabilities  specification — specifying  what  the  existing  OSS  system  does — may 
therefore  become  a  new  engineering  practice  and  methodology  that  can  be 
investigated,  modeled,  supported,  and  refined.  This  in  turn  may  then  lead  to 
principles  for  how  best  to  specify  software  system  capabilities. 

6.  Conclusions 

The  paper  reports  on  a  study  that  investigates,  compares,  and  describes  how 
the  requirements  engineering  processes  occurs  in  OSSD  projects  found  in  different 
communities.  A  number  of  conclusions  can  be  drawn  from  the  findings  presented. 

First,  this  study  sought  to  discover  and  describe  the  practices  and  artifacts 
that  characterize  the  requirements  for  developing  OSS  systems.  Perhaps  the 
processes  and  artifacts  that  were  described  were  obvious  to  the  reader.  This  might 
be  true  for  those  scholars  and  students  of  software  requirements  engineering  who 
have  already  participated  in  OSS  projects,  though  advocates  who  have  do  not  report 
on  the  processes  described  here  [11,  17,  42,  43].  For  the  majority  of  students  who 
have  not  participated,  it  is  disappointing  to  not  find  such  descriptions,  processes,  or 
artifacts  within  the  classic  or  contemporary  literature  on  requirements  engineering  [5, 
9,  23,  ,  40],  In  contrast,  this  study  sought  to  develop  a  baseline  characterization  of 
the  how  the  requirements  process  for  OSS  occurs  and  the  artifacts  (and  other 
mechanisms)  employed.  Given  such  a  baseline  of  the  "as-is"  process  for  OSS 
requirements  engineering,  it  now  becomes  possible  to  juxtapose  one  or  more  "to-be" 
prescriptive  models  for  the  requirements  engineering  process,  then  begin  to  address 
what  steps  are  needed  to  transform  the  as-is  into  the  to-be  [48],  Such  a  position 
provides  a  basis  for  further  studies  which  seek  to  examine  how  to  redesign  OSS 
practices  into  those  closer  to  advocated  by  classic  or  contemporary  scholars  of 
software  requirements  engineering.  This  would  enable  students  or  scholars  of 
software  requirements  engineering,  for  example,  to  determine  whether  or  not  OSSD 
would  benefit  from  more  rigorous  requirements  elicitation,  analysis,  and 
management,  and  if  so,  how. 
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Second,  this  study  reports  on  the  centrality  and  importance  of  software 
informalisms  to  the  development  of  OSS  systems,  projects,  and  communities.  This 
result  might  be  construed  as  an  advocacy  of  the  'informal'  over  the  'formal'  in  how 
software  system  requirements  are  or  should  be  developed  and  validated,  though  it  is 
not  so  intended.  Instead,  attention  to  software  informalisms  used  in  OSS  projects, 
without  the  need  to  coerce  or  transform  them  into  more  mathematically  formal 
notations,  raises  the  issue  of  what  kinds  of  engineering  virtues  should  be  articulated 
to  evaluate  the  quality,  reliability,  or  feasibility  of  OSS  system  requirements  so 
expressed.  For  example,  traditional  software  requirements  engineering  advocates 
the  need  to  assess  requirements  in  terms  of  virtues  like  consistency,  completeness, 
traceability,  and  correctness  [5,  9,  23,  ,  40],  From  the  study  presented  here,  it 
appears  that  OSS  requirements  artifacts  might  be  assessed  in  terms  of  virtues  like 
encouragement  of  community  building;  freedom  of  expression  and  multiplicity  of 
expression;  readability  and  ease  of  navigation;  and  implicit  versus  explicit  structures 
for  organizing,  storing  and  sharing  OSS  requirements.  "Low"  measures  of  such 
virtues  might  potentially  point  to  increased  likelihood  of  a  failure  to  develop  a 
sustainable  OSS  system.  Subsequently,  improving  the  quality  of  such  virtues  for 
OSS  requirements  may  benefit  from  tools  that  encourage  community  development; 
social  interaction  and  communicative  expression;  software  reading  and 
comprehension;  community  hypertext  portals  and  Web-based  repositories. 
Nonetheless,  resolving  such  issues  is  an  appropriate  subject  for  further  study. 

Overall,  OSSD  practices  are  giving  rise  to  a  new  view  of  how  complex 
software  systems  can  be  constructed,  deployed,  and  evolved.  OSSD  does  not 
adhere  to  the  traditional  engineering  rationality  found  in  the  legacy  of  software 
engineering  life  cycle  models  or  prescriptive  standards.  The  development  OSS 
system  requirements  is  inherently  and  undeniably  a  complex  web  of  socio-technical 
processes,  development  situations,  and  dynamically  emerging  development 
contexts  [2,  19,  29,  61, 62],  In  this  way,  the  requirements  for  OSS  systems 
continually  emerge  through  a  web  of  community  narratives.  These  extended 
narratives  embody  discourse  that  is  captured  in  persistent,  globally  accessible,  OSS 
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informalisms  that  serve  as  an  organizational  memory  [1],  hypertextual  issue-based 
information  system  [7,  34],  and  a  networked  community  environment  for  information 
sharing,  communication,  and  social  interaction  [13,  27,  58,  61].  Consequently, 
ethnographic  methods  are  needed  to  elicit,  analyze,  validate,  and  communicate  what 
these  narratives  are,  what  form  they  take,  what  practices  and  processes  give  them 
their  form,  and  what  research  methods  and  principles  are  employed  to  examine 
them  [19,  20,  29,  40,  53,  57,  62],  This  report  thus  contributes  a  new  study  of  this 
kind. 
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